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Description 

BACKGROUND OF THE INVENTION 

[0001 ] The present invention relates to network man- 
agement systems and to a framework and methods for 
such systems. 

[0002] Network management systems find applica- 
tion to the management of systems remotely via a tele- 
communications system. Network management sys- 
tems are known which permit the manipulation and con- 
trol of a large number and variety of objects over a net- 
work in accordance with a relatively limited set of com- 
mands, including operations such as GET, SET, AC- 
TION, CREATE and DELETE. An example of such a 
network management system is the so-called Telecom- 
munications Management Network (TMN) environment. 
[0003] The TMN environment provides an industry 
standard Common Management Information Protocol 
(CMIP) and supports X710/ISO 9595 Common Man- 
agement Information Services (CM IS) under that proto- 
col. These services allow manipulation of a large 
number and variety of objects over a network in accord- 
ance with a relatively limited set of commands, including 
operations such as GET, SET, ACTION, CREATE and 
DELETE. 

[0004] The physical configuration of the network on 
which the network management system is configured 
can take many different forms, including, by way of ex- 
ample, a public switched telephone network and/or a lo- 
cal area network and/or a dedicated network connecting 
computer and other equipment within a local area and/ 
or over a wider area or an open network such as the 
Internet or an intranet. The objects typically comprise 
parameters and methods used to model a piece of 
equipment, a component of that equipment, an opera- 
tion of the equipment or a component thereof, and so on. 
[0005] In the TMN environment, for example, objects 
are defined in accordance with the industry standard 
X722/ISO-10165-4 Guidelines for Definition of Man- 
aged Objects (GDMO). The GDMO defines data, or pa- 
rameter, types in accordance with the X208/ISO-8824 
Abstract Syntax Notation One (ASN. 1) and the 
X209/ISO-8825 Specification of Basic Encoding Rules 
for Abstract Notation One (BER) for data notation. 
These various industry standards are defined by the In- 
ternational Standards Organisation (ISO). 
[0006] GDMO is a formal descriptive language which 
is not directly understood by a computer. It is therefore 
necessary to convert GDMO into a computer-under- 
standable format. As there is no standard for such a 
process, this often leads to multiple interpretations, 
which in turn leads to inter-operability problems. 
[0007] In order to invoke the CM IS, it is necessary to 
provide an Application Programming Interface (API). 
Typically, APIs have been created using programming 
languages such as C or C++. However, a program- 
based API forthe ASN.1 and GDMO standards runs into 



difficulties when there is a need to expand the network 
services, for example by defining new types and in- 
stances of objects (e.g., a new type of workstation for a 
network manager). Another problem with existing net- 

s work management systems is that they are restricted as 
to the protocols which the network management agents 
can support. In other words, the conventional approach 
to providing an API is problematic in a dynamic network 
management environment. 

10 [0008] US patent 5,31 5,703 and US patent 5,367,633 
describe object-based systems which include a frame- 
work for permitting change notification functions. How- 
ever, these patents describe stand-alone systems. 
[0009] An article entitled "The Common Agent - A Mul- 

'5 tiprotocol Management Agent" by Newkerk et al, pub- 
lished in IEEE Journal on Selected Areas in the IEEE 
Journal on Selected Areas in Communications II (1993) 
December, No 9, describes a common agent that forms 
an implementation of an ISO compliant management 

20 agent that supports multiple management protocols and 
the run-time addition of new classes of managed ob- 
jects. Protocol processing in the common agent is con- 
trolled by separate processes called protocol engines. 
Each protocol engine is responsible, inter alia, for sup- 

25 plying an interface to a network stack and for dispatch- 
ing the managed objects. The common agent allows 
both the managed objects and the protocols to be added 
or removed dynamically to or from a system. 

30 SUMMARY OF THE INVENTION 

[001 0] One aspect of the invention provides a network 
agent for a telecommunications network, said network 
agent comprising: an extensible framework; one or 

35 more managed objects registerable with said frame- 
work; and one or more network adaptors registerable 
with said framework for a network communications pro- 
tocol for enabling access to said managed objects, 
wherein a said managed object is a bean which com- 

40 prises a set of properties, a set of methods for perform- 
ing actions, and support for events and for introspection. 
[001 1 ] The beans can be implemented as JavaBeans 
components (JavaBeans is a trademark of Sun Mi- 
crosystems, Inc.). Beans are reusable software compo- 

45 nents which can be manipulated visually in a builder tool 
(e.g. an editor or graphical user interface builder (GUI 
builder)). An example of a builder tool is the JavaBeans 
Development Kit. Further details about beans can be 
found in many different works, for example in a book 

so entitled Mastering JavaBeans by Lawrence Vanhelsuwe 
published by Sybex (ISBN 0-7821-2097-0). This is just 
one example of many broadly equivalent books on the 
market having "JavaBeans" in the title and describing 
the JavaBeans. Many of these works, including the book 

55 Mastering JavaBeans, supply the Bean Development 
Kit mentioned above. 

[0012] Beans vary in functionality, but they typically 
share certain common defining features providing a set 
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of properties, a set of methods and support for events 
and for introspection, also known as reflection. The 
properties allow beans to be manipulated programmat- 
ically and support customization of the bean. The meth- 
ods implement the properties. The support for events 
enables beans to fire events and define the events 
which can be fired. The support for introspection ena- 
bles the properties, events and methods of the bean to 
be inspected externally. 

[0013] This means that when developing managed 
objects with the network mariagement system, it is not 
necessary to know to which communications protocol 
the managed object will be accessed. 
[0014] An embodiment of the invention can provide 
an extensible framework for a network agent with man- 
aged objects and network adaptors which can be asso- 
ciated, or registered, with the framework, a flexible net- 
work agent, for example a network management agent, 
can be provided which can be extended in an adaptable 
manner to suit changing circumstances. By enabling the 
association, or registration, of different managed ob- 
jects as required, the extension of the structure to incor- 
porate new objects for managing new or changes re- 
sources can readily be enabled. By permitting selective 
connection of different network adaptors, which are 
preferably implements as objects, the protocols for man- 
aging the managed objects can be selected as required. 
[0015] Management services can be registered with 
the framework in a dynamic manner to provide a scala- 
ble management environment. One example of a man- 
agement service is a repository service. 
[0016] A repository service object can be registrable 
with the framework, the managed object(s) and/or the 
network adaptor(s) (and/or further management servic- 
es) being registrable with the repository service object, 
whereby the managed object and the network adaptors 
are registerable indirectly with the framework via the re- 
pository service object. The framework can then make 
access to the managed objects and network adaptors 
via, or by referencing, the repository object. The repos- 
itory service object effectively provides a connection 
mechanism between the framework and the managed 
objects and the network adaptors. This provides a par- 
ticularly flexible structure for dynamic extension of the 
agent structure. 

[001 7] The framework can comprise getter and setter 
properties and implements getter and setter methods for 
getting and/or setting objects and/or object methods. 
For providing the remote manipulation of the objects, the 
network adaptor(s) can be responsive to a received ex- 
ternal request to cause the framework to get a managed 
object method for the request and to return a subse- 
quent response. Where the repository service is provid- 
ed, the framework references the repository service for 
calling the managed object method. The framework can 
be arranged to effect add object and remove object func- 
tions for implementing dynamic scaling of the manage- 
ment structure. The framework can be preferably imple- 



mented as a bean including getter and setter properties, 
methods for implementing those properties and support 
for add object and remove object events. 
[0018] In accordance with a further aspect of the in- 

s vention, there is provided a method of providing agent 
services via a telecommunication network, said method 
comprising steps of: dynamically registering one or 
more managed objects with an extensible agent frame- 
work; registering one or more network adaptors for a 

10 network communications protocol with said framework; 
and enabling access to said managed object(s) via said 
network adaptor(s), wherein a said managed object is 
a bean which comprises a set of properties, a set of 
methods for performing actions, and support for events 

15 and for introspection. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0019] Embodiments of the present invention will be 
20 described hereinafter, by way of example only, with ref- 
erence to the accompanying drawings in which like ref- 
erence signs relate to like elements and in which: 



Figure 1 is a schematic representation of three sta- 
25 tions connected via a telecommunications network; 

Figures 2 and 2A form a schematic representation 

of a computer server for a station of Figure 1 ; 

Figure 3 is a schematic representation of an agent 

for a managed station; 
30 Figure 4 is an alternative representation of the 

agent of Figure 3; 

Figure 5 is an example of a configuration for an 
agent; 

Figure 6 is a flow diagram illustrating operations us- 
35 ing an agent as shown in Figure 5 ; 

Figure 7 is an example of a configuration of a man- 
agement system; 

Figure 8 is another example of a configuration of a 
management system; 
40 Figure 9 illustrates an aspect of the creation of the 
configuration of Figure 8; 

Figure 10 is a flow diagram illustrating operations 
of the system of Figure 8; 

Figure 1 1 is a flow diagram illustrating the operation 
45 of a naming service; 

Figure 1 2 is a flow diagram illustrating the operation 
of the creation of a generic agent; 
Figures 13 and 14 illustrate alternative operations 
of a compiler; 

so Figures 1 5A and 1 5B are used to illustrate the effect 
of compiling a management bean; 
Figures 16A and 16B are also used to illustrate the 
effect of compiling a management bean; and 
Figure 1 7 is a flow diagram illustrating steps in gen- 

55 erating a management system. 



3 



5 



EP 0 909 058 B1 



6 



DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0020] Figure 1 is a schematic representation of a 
multi-station network based system 1 with three sta- 
tions, or nodes, or machines 3, 4 and 5 connected via 
a network 2. The network 2 can be based on a public 
switched telephone network and/or a local area network 
and/or a dedicated network connecting computer and 
other equipment within a local area and/or over a wider 
area and/or an open network such as the Internet or an 
intranet, or combination thereof or indeed any other type 
of telecommunications network which can support the 
exchange of telecommunications management infor- 
mation. The network can have any desired structure, 
such as a level structure, a pyramidal hierarchy, etc. 
[0021] Any one or more of the stations 3, 4 or 5 can 
be configured as a network management station. In the 
example shown in Figure 1 , it is assumed that station 3 
is a management station and stations 4 and 5 are man- 
aged stations. It will be appreciated that any number of 
management stations and managed stations may be 
provided and that the three stations of Figure 1 are for 
illustrative purposes only. Also, the managing and man- 
aged functions could be interchanged or indeed both 
managing and managed functions could be supported 
at one and the same station. 

[0022] The stations can take on many forms. For the 
purposes of illustration it is assumed that both comprise 
computer workstations. Figure 2 is a schematic repre- 
sentation of the configuration of a computer workstation. 
As illustrated in Figure 2, this is implemented by a server 
computer 1 0 comprising a system unit 1 1 with a display 
8, keyboard and other input devices 9. Figure 2A is a 
schematic block representation of aspects of the con- 
tents of the system unit 11 . As illustrated in Figure 2A, 
the system unit includes a processor 17, memory 18, 
magnetic and/or optical disk drives 13 and 14, and a 
communications adaptor 16 for connection to one or 
more telecommunication lines 15 for connection to the 
telecommunications network 2. As illustrated in Figure 
2A, the components of the system unit are connected 
via a bus arrangement 1 9. It will be appreciated that Fig- 
ures 2/2A are a general schematic representation of one 
possible configuration for a server computer for forming 
a router. It will be appreciated that many alternative con- 
figurations could be provided. 

[0023] Where the workstation implements a manage- 
ment station, management application or applications 
and interface structures are typically provided by soft- 
ware which is stored in the memory of the workstation 
and executed by the processor of the workstation. 
[0024] Where the workstation implements a managed 
station, an agent is responsive to remote management 
requests via the network from the management applica- 
tions to provide an interface to managed objects at the 
managed stations. The agent and managed object 
structures are typically provided by software which is 



stored in the memory of the workstation and executed 
by the processor of the workstation. 
[0025] The objects typically comprise parameters and 
methods used to model a piece of equipment, a compo- 
s nent of that equipment, an operation of the equipment 
or a component or resource thereof, and so on. 
[0026] The management of a telecommunications 
network requires applications of various sizes and com- 
plexities. Heavy managers, middle managers, extensi- 
10 ble agents, smart agents and appliances all have a role 
in the management of a telecommunications network. A 
network management system incorporating the present 
invention provides an extensible agent framework al- 
lowing all of these different application types to be built 
15 on the same architecture. This extensible agent frame- 
work is provided by a component of the network man- 
agement system. Alternative terms for the extensible 
agent framework in this context could be a "dynamic 
framework" or "open framework" or "runtime compo- 
20 nent", although the terms "framework" or "extensible 
agent framework" will be used herein. 
[0027] The network management system is supplied 
with a set of core management services. A choice can 
be made from this set of services, and it can be extended 
25 to develop specific applications. Different services are 
loaded statically or dynamically into the framework to 
meet the requirements of a particular application. 
[0028] A managed object in an example of a network 
agent incorporating the present invention is preferably 
30 implemented as a bean, more preferably a JavaBeans 
component. A bean (and a JavaBeans component) is a 
reusable software component which can be manipulat- 
ed visually in a builder tool (e.g. an editor or graphical 
user interface builder (GUI builder). An example of a 
35 builder tool is the JavaBeans Development Kit. Beans 
vary in functionality, but they typically share certain com- 
mon defining features providing a set of properties, a 
set of methods for performing actions, and support for 
events and for introspection. The properties allow beans 
40 to be manipulated programmatically and support cus- 
tomization of the bean. The methods implement the 
properties. The support for events enables beans to fire 
events and define the events which can be fired. The 
support for introspection enables the properties, events 
45 and methods of the bean to be inspected from external- 
ly. Operations such as GET, SET, ACTION, CREATE 
and DELETE can be supported. 
[0029] A managed object in the agent is manageable 
as soon as it is registered with the framework. This ar- 
so rangement enables an agent developed in accordance 
with this network management system to be managea- 
ble with minimal impact on the design of the agent. 
[0030] As indicated above, an example of the network 
management system uses the JavaBeans component 
55 model, thereby easing the development of applications. 
In this example, all of the core management services 
are provided as JavaBeans components. Thus access 
can be had to them using a Java application builder, 
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such as the well known JavaBeans Development Kit. 
Managed objects are developed as JavaBeans compo- 
nents. A JavaBeans component in the network manage- 
ment system agent can be accessed locally or remotely. 
This means that when developing managed objects with 
the network management system, it is not necessary to 
know to which communications protocol the managed 
object will be accessed. 

[0031] The network management system simplifies 
the development of extensible agents. A set of core 
management services that the network management 
system provides can be extended and loaded into an 
agent while it is running. Most of the core management 
services are optional. This means that an agent devel- 
oped using the network management system need only 
implement the service it uses. This feature enables the 
development of agents of differing sizes and complexi- 
ties. 

[0032] Agents developed using the network manage- 
ment system are also smart agents. A smart agent pro- 
vides the services needed to process management re- 
quests. In a smart agent, much of the processing can 
be done locally in the agent itself, reducing the load on 
the network connection between the agent and manag- 
ing system. 

[0033] Figure 3 illustrates an aspect of the architec- 
ture of a network management system agent, including 
the relationships between the components of the net- 
work management system. Figure 3 also shows the re- 
lationship between the network management system 
agent and management applications. 
[0034] As shown in Figure 3, the network manage- 
ment system agent consists of a number of components 
inside a Java virtual machine (VM). These include: 

m-beans 29; 

the framework 24; 

core management services 25, 26, 27, 28; 
managed objects adaptor servers 30, 32, 34, 36 
and 38. 

These components will be described in more detail be- 
low. 

[0035] A managed object is a software abstraction 
of a resource that is controlled and monitored by an 
agent. A managed object (eg. 28) is referred to as a 
management bean or m-bean. In an example of the net- 
work management system, all m-beans are implement- 
ed as JavaBeans components. Therefore, these can be 
accessed using a conventional Java application builder, 
such as the JavaBeans Development Kit mentioned 
earlier. 

[0036] As for any other managed object, an m-bean 
has a set of properties, can perform a set of actions, and 
can emit a set of notifications or events. The network 
management system enables a distinction to be made 
between a read-only and a read-write property in an m- 
bean. 



[0037] An m-bean is manageable as soon as it is reg- 
istered with the framework 24. When an m-bean is reg- 
istered, an object name is associated with it. The object 
name uniquely identifies the m-bean within the m-bean 
s repository (see below). It enables a management appli- 
cation to identify the m-bean on which it is to perform a 
management operation. The object name of an m-bean 
is an arbitrary name that does not depend in any way 
on how the m-bean is implemented. 
w [0038] The framework 24 controls the management 
services and m-beans of an agent 20 are loaded into 
the framework 24. The framework, or runtime compo- 
nent, 24 is a JavaBeans component which comprises a 
set of properties, a set of methods for performing ac- 
15 tions, and support for events and for introspection. The 
properties include getter and setter properties. The 
methods include methods to implement the getter and 
setter properties. The framework is also able to effect 
add object and remove object functions. 
20 [0039] Whenever an agent 20 is requested to perform 
a management operation received through a network 
adaptor, the framework 24 calls the appropriate service 
to perform the requested operation. The framework 24 
also handles communications between m-beans 28 and 
25 the managed object adaptor servers 30-38. An m-bean 
can query the framework 24 to obtain information on oth- 
er m-beans 28 loaded into the same instance of the 
framework 24. Only one instance of the framework 24 
is permitted within a virtual machine 22. 
30 [0040] The network management system provides a 
number of core management services. In an example 
of the system, the core management services are de- 
fined as Java interfaces. The core management servic- 
es are optional. This means that an agent developed 
35 using the network management system need only im- 
plement the services it uses. The core management 
services can be registered as m-beans, which allows 
some management operations to be formed on them for 
tuning their behaviour. 
40 [0041] In the preferred example of the system, the 
core management services are provided as JavaBeans 
components. It is therefore possible to access them us- 
ing a conventional Java application builder, such as the 
JavaBeans Development Kit mentioned earlier. 
45 [0042] A number of the core management services 
are now to be described. 

[0043] The m-bean repository service 27 obtains 
pointers to m-beans. Each time an m-bean is registered 
with the framework 24, the framework 24 calls the m- 
so bean repository service 27 to store the identity of the m- 
bean. A name is associated with an m-bean. When que- 
rying the m-bean repository 27, agent and manager ap- 
plications can identify an m-bean by its name. Different 
implementations of the m-bean repository service 27 
55 are possible. One implementation uses a relational da- 
tabase for storing persistent m-beans, whereas another 
implementation employs simple memory for storing 
non-persistent m-beans. 
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[0044] Bearing in mind the structure provided by the 
repository unit, an alternative representation of the re- 
lationship between components of the agent is illustrat- 
ed in Figure 4. This takes account of the registration of 
the beans for the managed object adaptor servers, the 
management services and the managed objects with 
the m-bean repository service bean. 
[0045] A filtering service 29 selects m-beans to be 
the subject of a management operation. Selection is 
based on the presence and values of specific attributes. 
For example, a filter could select all the m-beans for 
which the attribute color is set to red. 
[0046] A metadata service 25 provides information 
on the structure of an m-bean. For example, the frame- 
work 24 queries the metadata service 25 to access 
methods for getting and setting up a property within an 
m-bean. The metadata service 25 is based on the Re- 
flection API provided by the JavaBeans Development 
Kit for performing introspection. 

[0047] A dynamic class loading service loads new 
classes into the framework 24. A new class is loaded 
when the remote entry requests the creation of instanc- 
es of a class that is not loaded into the framework 24. A 
new class can be loaded from a remote class server. 
The dynamic loading service also enables core man- 
agement services to be added to a network manage- 
ment system agent while it is running. For example, an 
agent could be started without a filtering service. Then, 
later on, the filtering service could be added dynamically 
to the agent when it is required. 
[0048] An access control service can be provided 
to control access to m-beans. Before attempting to per- 
form a management operation on an m-bean, the frame- 
work 24 can be arranged to query the access control 
service to verify that the operation is valid. 
[0049] An event service can be provided to receive 
event reports from m-beans and to forward them to any 
entity that has requested to receive them. 
[0050] A relationship service can be provided to en- 
able relationships between m-beans to be defined when 
they are required. The relationships do not need to be 
defined in advance. Information on the relationships be- 
tween m-beans is not stored with the m-beans them- 
selves, but can be obtained from the relationship serv- 
ice. 

[0051] A dynamic native library loading service 

can be provided for loading native code into the frame- 
work 24. A native library can be loaded when a new 
class that includes native code is loaded. The library 
loaded depends on the hardware platform and operating 
system on which the framework is running. The native 
library can be loaded from a remote entity. 
[0052] There now follows a description of the man- 
aged object adaptor servers 30-38. 
[0053] A managed object adaptor server is a proto- 
col adaptor that provides an abstraction of a communi- 
cations protocol. Each managed object adaptor server 
provides access to m-beans through a particular com- 



munications protocol. A managed object adaptor server 
enables management applications to perform manage- 
ment operations on a network management system 
agent. 

s [0054] For a network management system agent to 
be manageable, it is connected via at least one man- 
aged object adaptor server. However, a network man- 
agement system agent can be connected to any number 
of managed object adaptor servers, allowing it to be 

10 queried by remote management applications that use 
different protocols. 

[0055] The network management system provides 
managed object adaptor servers for standard and pro- 
prietary protocols. 
15 [0056] For example, managed object adaptor servers 
can be provided for one or more of the standard proto- 
cols: HTML/HTTP; SNMP; and CORBA, by way of ex- 
ample. 

[0057] The managed object adaptor servers for 
20 standard protocols communicate directly with the man- 
agement applications that use them. 
[0058] For example, an HTML/HTTP managed object 
adaptor server enables a user to use a web browser to 
view management information contained in m-beans 
25 and to perform management operations on a network 
management system agent. The HTTP/HTML managed 
object adaptor server obtains management information 
from m-beans and generates HTML pages representing 
this management information. 
30 [0059] An SNMP managed object adaptor server can 
be arranged to use a specially defined SNMP manage- 
ment information base (MIB) to enable the SNMP man- 
ager to perform management operations on a network 
management system agent. 
35 [0060] The network management system can also be 
arranged to provide managed object adaptor servers for 
one or more of the following proprietary protocols: RMI; 
Java/HTTP; and Secure Sockets Layer (SSL). In one 
example of the network management system, a man- 
40 aged object adaptor client offers a Java API. According- 
ly, any management application that uses a managed 
object adaptor client will be written in Java language. 
[0061 ] Agents developed using the network manage- 
ment system can be managed using different commu- 
45 nications or management protocols. To be managed us- 
ing a standard management protocol, a network man- 
agement system agent needs to be connected to the 
managed object adaptor server for that protocol. The 
managed object adaptor service for standard protocols 
so communicates directly with the management applica- 
tions that use them. 

[0062] An example of this structure, using the agent 
representation of Figure 4, is shown in Figure 5, where 
the agent is accessed by means of a web browser 46. 
55 Here an HTML adaptor allows beans to be mapped to 
an HTML page. The use of a protocol such as HTML 
enables the browser 46 at the client station 90 to browse 
beans at the remote station 20 and access and where 
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necessary modify them using conventional web browser 
functions. In accordance with the structure shown in Fig- 
ure 4, the repository service 27 is registered with the 
framework 24, and the HTML adaptor 34 and the bean 
(s) 29 are registered with the repository service, where- 
by the bean(s) are effectively registered with an HTML 
page supported by the HTML adaptor 34. In Figure 5 
like reference numerals relate to like features of the ar- 
rangement shown in Figure 4. 

[0063] Figure 6 is a flow diagram illustrating steps for 
enabling the modification of properties of the beans in 
the remote machine. In step 92, the HTML adaptor 34 
is initiated in the virtual machine 22 at the remote station 
20 and in step 94 the bean(s) 29 of that virtual machine 
which are to be accessible remotely are registered with 
the framework, or more particularly with the repository 
service 27 as described above. This means that when 
the HTML adaptor queries the framework 24, the frame- 
work 24, with reference to the repository service, is able 
to identify the beans 29 to be accessed and to permit 
access thereto by the HTML adaptor. 
[0064] The HTML adaptor 34 allows communication 
over the network using conventional HTTP exchanges. 
It behaves as an HTTP server. When it receives a re- 
quest, it dynamically generates a page containing a list 
of beans (objects) 29 currently registered with the re- 
pository object 27. 

[0065] A bean is represented in HTML as an HTML 
table wherein: 

a first column contains a property name; 

a second column contains a property type; 

a third column contains the access right (read/ 

write); 

a fourth column contains a property value. 

[0066] As mentioned above, if the property is read/ 
write, an HTML form is generated. 
[0067] In step 96, the beans are displayed at the client 
station (represented by display 98) using the HTML rep- 
resentation of a bean as described above by accessing 
the HTML page using a conventional web browser 
which communicates with the HTML adaptor using HT- 
TP exchanges. The user is able then to select, at step 
1 00, a bean using conventional web browser functions. 
The web browser will then issue an HTTP GET request 
to the HTML adaptor 34. The HTML adaptor employs 
introspection to extract the bean properties and then re- 
turns an HTML post response to the browser, whereby 
the browser may display the properties, and possibly al- 
so the actions and events supported by the bean, as 
represented at 1 02. By further use of the browser using 
conventional browser functions, the user is able to se- 
lect and specify modifications to aspects of the bean, for 
example changes to the properties. By a further ex- 
change of HTML GET and/or SET requests and POST 
responses, the web browser and the HTML adaptor are 
able to modify, at step 1 04, the corresponding properties 



of the bean at the remote station and to display these 
changes to the user at the client station. 
[0068] Thus, this mechanism provides a computer- 
implemented method of accessing from a client ma- 
s chine an object such as a bean at a remote machine via 
a telecommunications network by mapping the object to 
an externally accessible machine page at the remote 
machine and browsing the object via the machine page 
using a browser. 
w [0069] Another example of the structure shown in Fig- 
ure 3, this time using the representation of Figure 3, is 
shown in Figure 7, where a network management sys- 
tem agent 20 is managed by an SNMP manager appli- 
cation. In Figure 7 like reference numerals relate to like 
15 features of the arrangement shown in Figure 3. 

[0070] An example of a network management system 
represented in Figure 8 provides an adaptor API to en- 
able Java management applications to communicate 
with the network management system agents. The 
20 adaptor API provides managed object adaptor clients 
for accessing managed objects through a particular 
communications protocol. The network management 
system defines a representation of m-beans for Java 
management applications and provides a compiling tool 
25 for generating such a representation automatically from 
an m-bean. A name service is supplied to allow Java 
management applications to be independent of a par- 
ticular communications protocol. 
[0071 ] A managed object adaptor client is an abstract 
30 Java class that enables Java management applications 
to access managed objects. The programmatic repre- 
sentation of the managed object to the Java manage- 
ment application is determined by the managed object 
adaptor client. Such a mechanism allows different rep- 
35 resentations of the same managed object to be present- 
ed to different Java management applications. The net- 
work management system provides managed object 
adaptor clients for accessing managed objects through 
one or more of the following protocols: RMI; HTTP; and 
40 SSL. 

[0072] The managed object adaptor clients provide a 
definition of an adaptor managed object interface. The 
adaptor managed object interface enables Java man- 
agement applications to perform one or more of the fol- 
45 lowing management operations on a network manage- 
ment system agent: 

retrieve m-beans; 

get or set the properties of remote m-beans; 
so - call methods of remote m-beans; 
create instances of m-beans; 
delete m-beans; and 

receive events emitted by remote m-beans. 

55 [0073] A managed object adaptor client provides a 
Java management application with "handles" on man- 
aged objects in a remote agent. These handles enable 
the Java management application to manipulate the 
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managed objects directly. The Java management appli- 
cation does not need information on the protocol used 
by the managed object. All the Java management ap- 
plication needs is the class of object that the managed 
object represents. For example, a Java management 
application for handling accounts uses an abstract class 
for representing accounts. To manipulate an account, 
the Java management application obtains an account 
managed object from the managed object adaptor cli- 
ent. It then casts the account managed object into the 
abstract class that represents the account. In this way, 
the application code is independent of how the managed 
object is implemented. 

[0074] Figure 8 is a schematic representation of the 
relationship between a client bean (c-bean) 54 and an 
m-bean 28. A c-bean 54 is a representation of an m- 
bean to a Java management application. In the pre- 
ferred embodiment of the invention, a c-bean 54, like an 
m-bean 28, is implemented as a JavaBeans compo- 
nent. A c-bean 54 defines how a Java management ap- 
plication accesses an m-bean 28. 
[0075] As seen in Figure 8, a c-bean 54 comprises a 
managed object interface (MO interface) 56 which de- 
fines which of the methods of an m-bean are accessible 
to a Java management application, and a managed ob- 
ject stub (MOStub) 58 that implements the methods de- 
fined in the MO interface 56. 

[0076] A Java management application obtains a ref- 
erence to a c-bean by using an adaptor MO interface 
60. The adaptor MO interface instantiates the c-bean 
54. The same implementation of a c-bean 54 can run 
on any managed object adaptor client that implements 
the adaptor MO interface 60. Different implementations 
of the same managed object can be presented to differ- 
ent Java management applications. Therefore, a single 
m-bean can be associated with several c-beans 54. 
[0077] A Java management application performs 
management operations on an m-bean by calling meth- 
ods of its associated c-bean 54. To the Java manage- 
ment application, a c-bean 54 is a local representation 
of the remote Java object (an m-bean 28). 
[0078] The adaptor MO interface 60 instantiates the 
c-bean 54. The same implementation of a c-bean can 
run on any managed object adaptor client 62 which im- 
plements the adaptor MO interface 60. Different repre- 
sentations of the same managed object can be present- 
ed to different Java management applications. Thus, a 
single m-bean can be associated with several c-beans. 
[0079] A Java management application performs 
management operations on a m-bean by calling meth- 
ods of its associated c-bean. To the Java management 
application, a c-bean is a local representation of a re- 
mote Java object (an m-bean). 

[0080] Figure 9 is a schematic representation of the 
generation of a c-bean 54 from an m-bean. In an em- 
bodiment of the invention a c-bean is generated auto- 
matically from an m-bean 28 using the Reflection API. 
The generated c-beans exhibit the same properties, 



methods and events as the m-beans. This is the case, 
for example, where no access control policy is enforced. 
[0081 ] In order to provide the automatic generation of 
a c-bean 54 from an m-bean 28, a compiler 60 takes as 

s an input the m-bean 28 and generates as an output the 
MO interface and MO stubs of a c-bean 54. For exam- 
ple, when an m-bean 28 representing a Java class 
named account is compiled, the compiler 60 generates 
an MO interface 56 named accountMO and a Java class 

10 named accountMOSTUB 58, which implements the ac- 
countMO interface 56. 

[0082] A Java management application can be devel- 
oped using the MO interface definitions. By loading dif- 
ferent stubs, the adaptorMO interface can modify the 
15 behaviour of the Java management application at run 
time. For example, if read-only stubs are loaded, the 
Java management application will not be able to modify 
the properties in the m-bean 28. 
[0083] The compiler 60 can generate read-only or 
20 read-write stubs. The generated stubs make use of the 
adaptorMO interface. Therefore, their behaviour is the 
same on any managed object adaptor client that imple- 
ments the adaptorMO interface, regardless of the imple- 
mentation of the managed object adaptor client. 
25 [0084] Figure 1 0 is a block diagram of steps for ac- 
cessing a bean at a remote (server) station from a local 
management (client) station using a structure as shown 
in Figure 8. 

[0085] The management application (e.g. a Java 
30 management application) at the management station 
generates, at step 80, a get request to the adaptorMO 
at the client station. The adaptorMO, with the Mostub 
and the network adaptor at the client station generate, 
at 81 , a request in accordance with an appropriate net- 
35 work protocol (e.g. HTTP). 

[0086] Thus the request sent via the network to the 
managed system could, for example, be in the form of 
a GET request for a management property of a man- 
aged object. 

40 [0087] The appropriate managed object adaptor serv- 
er 30-38, depending on the protocol used, receives the 
external request at step 82. It will then access, at step 
83, the framework 24 to get an appropriate method. The 
framework gets, at step 83, a managed object method 
45 for the request and returns, at step 84, the management 
property of the managed object to the adaptor, which in 
turn returns, at step 85, composes a return message 
with the result in accordance with the same network pro- 
tocol (e.g. HTTP). The result message is received, at 
so step 86, at the client adaptor and adaptorMO, which re- 
turns the result to the management application. 
[0088] A name service is provided which allows man- 
agement applications to be independent of a particular 
communications protocol. Java management applica- 
55 tions use the name service to determine which managed 
object adaptor client to use for accessing an agent. Fig- 
ure 1 1 is a schematic flow diagram illustrating the oper- 
ation of the name service. 
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[0089] In step 62, the management application pass- 
es the identity of the agent to be accessed to the main 
service. 

[0090] In step 64, the name service returns the class 
name of the managed object adaptor client, for example 
sunw.jaw.moa. rmi in the case of an agent access 
through the Java RMI system. 

[0091] In step 66, the Java management application 
uses its default class loader to dynamically load the 
managed object adaptor client and instantiate it. The 
Java management application can then interact with the 
agent through the managed object adaptor client, re- 
gardless of the communications protocol. 
[0092] As mentioned above, a management bean, or 
m-bean is a managed object in a network management 
system agent. A managed object is a software abstrac- 
tion of a resource that is controlled and monitored by the 
agent. In an example of a network management system, 
all m-beans are implemented as JavaBeans compo- 
nents. They can be accessed using a conventional Java 
application builder, such as the Java Beans Develop- 
ment Kit. Within an m-bean, it is possible to call and use 
services provided by the network management system. 
[0093] A JavaBeans component includes properties 
which form discrete, named attributes which can affect 
the appearance or the behaviour of the JavaBeans com- 
ponent. For example, an m-bean representing an Eth- 
ernet driver might have a property named Ipackets that 
represents the number of incoming packets. Properties 
can have arbitrary values, including both built-in Java 
end types and class or interface types such as Java.awt. 
color. Properties are always accessed via method calls 
on the object that owns them. For readable properties 
there is a get method to read the property value. For 
writeable properties, there is a set method to allow the 
property value to be updated. 

[0094] A default design pattern can be used for locat- 
ing properties: 

public PropertyType get PropertyNameQ; 
public void set PropertyName (PropertyType val- 
ue); 

[0095] If a class definition contains a matching pair of 
get PropertyName and set PropertyName methods with 
the return type of the getter corresponding to the param- 
eter type of the setter, then these methods define a read- 
write property. If a class definition contains only one of 
these methods, the name defines either a read-only or 
write-only property called PropertyName. 
[0096] In addition for Boolean properties, it is possible 
to define a get method using the following design pat- 
tern: 

public boolean is Property NameQ; 

[0097] The is PropertyName method may be provided 
instead of a geXPropertyName method where it may be 



provided in addition to a qeXPropertyName method. 
[0098] An index property is an array Property Element 
[], that is accessed by methods of the form: 

s public PropenyElement qeXPropertyName (int in- 

dex); 

public void setPropertyName (int index, Proper- 
tyElementb). 

w [0099] If a class definition contains either kind of 
method, PropertyName is an index property. These 
methods can be used to read and write a property value. 
These methods can be defined in addition to the meth- 
ods defined for simple properties. Therefore, an index 

15 property can be represented by four accessor methods. 
[01 00] By default, the following design pattern is used 
to determine which events an m-bean can multicast: 

public void addEventListenerType(EventListener- 
20 Type a); 

public removeEventListenerType(EventListener- 
Type a); 

[01 01 ] Both of these methods take the EventListener- 
25 Type type argument, where the EventListenerType type 
extends the java.util.EventListener'mterface, where the 
first method starts with add, the second method starts 
with remove, and where the EventListenerType type 
name ends with Listener. 
30 [0102] This design patent assumes that the Java 
bean is acting as a multicast event source for the event 
specified in the EventListenerType interface. 
[0103] To conform to the JavaBeans model, all public 
methods of a JavaBeans component should be exposed 
35 as external methods within the component environment 
for access by the components. By default, this includes 
property accessor methods, and in the event listener 
registry method. 

[01 04] In addition to the JavaBeans component mod- 
40 el for design pattern elements, the network manage- 
ment system can define an action as a public method of 
an m-bean that makes sense to be called remotely. Ac- 
tion facilitates the differentiation of an m-bean public 
method which is exposed for other local m-beans from 
45 public methods that can be called remotely. The design 
pattern for an action is as follows: 

public AnyJavaType perform/4n/4cf/on (AnySigna- 
ture); 

50 

[0105] M-beans can contain native libraries, that is a 
library not written in the language (e.g. Java) of the m- 
bean. The network management system can provide a 
mechanism for loading a native library from the same 
55 remote class server as the m-beans. To enable an m- 
bean to use this mechanism, a static load Library method 
of the Framework class can be called in which the caller 
includes a reference to the Java class of the caller. Such 
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information is used by the framework 24 for identifying 
the class loader by which the class is loaded. 
[0106] The core management services mentioned 
above are for many of the management operations com- 
mon to all agents, thereby simplifying the development s 
of agents. By providing these core services, the network 
management system enables efforts to be concentrated 
on developing those parts of an agent which are specific 
to a particular application, namely the m-beans and the 
applications to control and manage them. 10 
[0107] Figure 12 is a schematic flow diagram of the 
initialisation of a network management system agent 20. 
The initialisation process comprises: 

in step 70, creating an instance of the framework 24; '5 
in step 72, adding the m-bean repository service 27; 
in step 74, adding the metadata service 29; and 
in step 76, adding at least one managed object 
adaptor server (30-38) so that the agent can be ac- 
cess by management applications. 20 

[0108] Once the network management system agent 
20 has been initialised, no further management services 
need to be added before an agent is started. These can 
be added dynamically to the agent while it is running. 25 
[0109] The framework 24, controls the management 
services and m-beans of an agent 20 developed using 
the network management system. In the preferred em- 
bodiment it is implemented by the Java class java.jaw. 
agent. cmf. Framework. An agent must contain one in- 30 
stance of the framework, that is, in the preferred embod- 
iment, one instance of the java.jaw.agent. cmf. Frame- 
work class. 

[01 10] In the preferred embodiment, m-beans can be 
managed only if they are registered with an object name 35 
in the m-bean repository 27 of the agent 20. Accordingly, 
the m-bean repository service 27 is added in step 72 
before the agent 20 becomes operational. The m-bean 
repository service 27 is used for storing and retrieving 
the association between an m-bean and its object name. 40 
The m-bean repository service of the preferred embod- 
iment is defined as the Java interface java.jaw.agent. 
services. MoRepSrvlf. An agent can only be associated 
with the one m-bean repository service at any one time. 
However, it is possible to change the m-bean repository 45 
service with which the agent is associated while the 
agent is running. 

[0111] The m-bean repository can be implemented as 
a volatile storage or as a persistent storage. In a volatile 
repository, all the information on m-beans is stored in so 
memory. All of the information in a volatile repository is 
lost when the agent is stopped. Accordingly, when an 
agent is started, with a volatile repository, it has to reload 
the information in the repository. With a persistent re- 
pository, all the information on m-beans is stored in a 55 
database whereby the information in a persistent repos- 
itory is not lost when the agent is stopped. It is also pos- 
sible to implement a mixed repository whereby informa- 



tion on m-beans is stored in memory or in a database. 
[0112] The metadata service referenced above is 
used to obtain the properties and actions supported by 
an m-bean. A preferred implementation of the metadata 
service is based on the Reflection API provided by the 
known Java Development Kit for performing introspec- 
tion. 

[0113] As mentioned above, at least one managed 
object adaptor service should be running in the server 
virtual machine as the network management system 
agent. The network management system does not re- 
quire a managed object adaptor server to conform to a 
specific interface definition or implementation. The man- 
aged object adaptor server is arranged to access the 
framework 24 to retrieve and change information con- 
tained in the agent. The managed object adaptor serv- 
ers provided are implemented as m-beans. Examples 
of managed object adaptor servers have been de- 
scribed above. In the preferred embodiment of the in- 
vention, the managed object adaptor servers are imple- 
mented as appropriate Java classes. 
[0114] For example, an RMI managed object adaptor 
server can be implemented as a Java class sunw.jaw. 
agent. adaptor.rmi.AdaptorServerlmpl. It enables Java 
management application to access an agent using the 
Java remote method invocation (RMI) system. As de- 
scribed above, a Java management application access- 
es this server through a managed object adaptor client 
implemented as the Java class sunw.jaw.agent. adaptor. 
rmi.AdaptorClient. 

[0115] Core management services can be added to 
an agent while it is running, once the agent has been 
initialised as described above. It is possible to add a core 
service to an agent in either of the following ways: 

directly calling a set method for the service within 
the Framework class; 

adding the service to the m-bean repository in the 
same way as for an m-bean. 

[0116] Adding a core management service directly 
gives faster performance than adding a core manage- 
ment service to the m-bean repository. This is because 
the framework does not need to query the m-bean re- 
pository in order to obtain the service. However, certain 
restrictions can apply to a core management service 
that has been added directly: 

the service is not visible to remote applications; and 
it is not possible to store information on the service 
in persistent storage. 

[0117] Accordingly, where it is desirable for a core 
management service to be visible to remote applica- 
tions, it is necessary to add the service to the m-bean 
repository. If it is desired to store information on a core 
management service in persistent storage, it is also nec- 
essary to add the service to the m-bean repository. The 
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m-bean repository to which the service is added, must 
support persistent storage. 

[0118] A Class Service Name contains names by 
which the framework 24 identifies the services that are 
implemented for an agent. The framework 24 retrieves 
the service it requires as follows: 

1 . The framework 24 checks if a service has been 
defined using a direct set method. If a service has 
been defined in this way, the framework 24 uses this 
service. 

2. If the service has not been defined using a direct 
set method, the framework queries the m-bean re- 
pository to obtain all the m-beans that are instances 
of the class that implements the service. For exam- 
ple, for the metadata service, the framework 24 
queries the m-bean repository to obtain all the in- 
stances of the class named ServiceName.META. 

if the repository contains several instances of 
the class, the framework 24 uses the first in- 
stance returned by the m-bean repository, 
if the m-bean repository contains no instances 
of the class, the framework throws a Service- 
NotFound Exception. 

[01 1 9] Various operations can be performed in a net- 
work management service agent. For example, an ob- 
ject in an agent can use core management services for: 

instantiating m-bean; 

registering m-beans with the m-bean repository; 
retrieving m-beans from the m-bean repository; 
getting and setting the values of properties within 
m-beans; and 

defining relationships between m-beans. 

[01 20] An object name uniquely identifies an m-bean. 
Management applications use object names to identify 
the m-beans on which to perform management opera- 
tions. Any naming scheme could be used. For example, 
in the preferred embodiment of the invention, a naming 
scheme defined by Microsoft Corporation for the Hyper 
Media Management Scheme (HMMS) could be used. 
[0121] In order to instantiate an m-bean, one of the 
following methods of the Framework class can be 
called: 

newObject to user default storage mechanism for 
storing the m-bean; 

newDBObject to specify the m-bean is persistent. 

[0122] With either of these methods, it is necessary 
to provide: 

the Java class of the m-bean to be instantiated; and 
the object name to be used for registering the m- 
bean. 



[01 23] By default, the framework 24 uses the default 
class loader to locate the Java class of the m-bean to 
be created. It then creates an instance of the class. 
Once the m-bean has been instantiated, it is initialised 
s and registered so that it is accessible to the framework 
24. It is possible to initialise and register an m-bean by 
using: 

a method defined in the m-bean itself; or 
10 - the framework 24. 

[0124] For initialising a register of an m-bean using a 
method defined in the m-bean itself, the Java class def- 
inition of the m-bean should contain: 

15 

an initialisation method; 

the code required to enable the m-bean to register 
itself with the m-bean repository. 

20 [0125] Once the m-bean has been instantiated, the 
framework 24 uses the metadata service 27 to find the 
initialisation method in the newly created m-bean. If 
such a method is present in the m-bean, the framework 
24 calls it giving: 

25 

a reference to itself as a first parameter; 

the object name for use in registering the m-bean 

as a second parameter. 

30 [0126] The m-bean is therefore able to register itself 
with the m-bean repository using the code provided. 
[0127] If an m-bean is not provided with the initialisa- 
tion method, the framework initialises and registers the 
m-bean using functions provided for this purpose. 
35 [0128] Registering a JavaBeans component with the 
m-bean repository 25 enables the component to be 
managed by the agent 20. Registering the JavaBeans 
component does not require modification of code within 
the JavaBeans component itself. Instead, all that is re- 
40 quired is the addition of code for registering it in the m- 
bean repository. Therefore, it is possible to register any 
existing JavaBeans component in the m-bean reposi- 
tory. Once registered, the agent 20 manages the Java- 
Beans component in the same way as any m-bean. 
45 When an m-bean is registered, it is assigned an object 
name. An object name can be explicitly specified. If an 
object name is not explicitly specified, the framework 24 
assigns a default name to the m-bean. 
[0129] The network management system provides 
so services for retrieving m-beans from the m-bean repos- 
itory. These services enable the retrieval of m-beans us- 
ing: 

pattern matching on the object name; or 
55 - queries (filters) on the Java properties they contain. 

[01 30] By using pattern matching on the object names 
of m-beans, it is possible to retrieve: 
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a specific m-bean using its full object name; 

a set of m-beans sharing the same logical class as 

expressed in the object name; 

a set of m-beans sharing the same domain name; or 

all the m-beans contained in an agent. 

[01 31 ] Using queries enables the retrieval of m-beans 
according to Java properties and their values within m- 
beans. The m-bean repository evaluates properties if it 
is able to do so. Otherwise the framework evaluates 
queries itself. To determine whether a repository is able 
to assess queries, the framework causes a query meth- 
od for this purpose. 

[0132] The network management system provides 
services for getting and setting properties of m-beans. 
If the agent provides a metadata service, in a call to the 
get or set method of the m-bean, all that needs to be 
supplied are: 

the name of the property to be retrieved or set; 
the object name of the m-bean that contains the 
property. 

[01 33] If the agent does not provide a metadata serv- 
ice, it is still possible to call directly to the get or set meth- 
od of an m-bean. In this case it is also necessary to sup- 
ply to the caller the name and signature of the method 
to call. 

[0134] A relationship service enables relationships 
between m-beans to be defined when they are required. 
The relationships do not need to be defined in advance. 
Information on the relationships between m-beans is not 
stored with the m-beans themselves, but is stored with 
the relationship. A relationship needs to be registered 
with the m-bean repository. A relationship is defined by: 

a set of roles, for example in an ownership relation- 
ship a person owns a book and a book is owned by 
a person; 

a degree which corresponds to the number of re- 
quired roles in a relationship. 

[0135] The m-beans involved in a relationship are re- 
ferred to in a relationship by their object names. A spe- 
cific class loader can be added to the agent at start-up 
or while the agent is running. It is possible to have sev- 
eral class loaders within the same agent, provided that 
they are all registered with the m-bean repository. When 
the creation of a new object is requested, it is possible 
to specify the class loader to be used for loading the 
object. In this case the class loader is identified by its 
object name. The system provides several implementa- 
tions of a network class loader, each implementation us- 
ing a different protocol and requiring a different class 
server. 

[0136] The system provides event handling services 
for filtering, logging and forwarding events through dif- 
ferent communications protocols. To emit an event, a 



send event method is called. When this method is 
called, the framework 24 retrieves all the m-beans cor- 
responding to an event handling service and calls an 
event handling method of each event handler retrieved. 

s This method is responsible for handling the events. 
[0137] Figure 9 is a schematic representation of the 
compiling of a c-bean 54 from an m-bean 28. The com- 
piler 60 implements one translation scheme for gener- 
ating c-beans. It is, however, possible to implement dif- 

10 ferent translation schemes depending on the require- 
ments. 

[0138] Figure 13 illustrates an example of the output 
of the compiler 60 for compiling a single m-bean called 
A. Figure 14 shows the output of the compiler 60 if a 
15 compiled m-bean includes aListenerior a specific event 
AnEvent. 

[0139] Thus, if the m-bean contains listeners, the 
compiler 60 generates: 

20 - a Java interface for the listener to be included in the 
MO interface; 

a listener stub which is an implementation of the m- 
bean listener for catching m-bean events and for- 
warding them to the framework 24; and 
25 - a Java management application's view of the event 
associated to the listener referred to as EventMO. 

[0140] The compiler 60 parses an m-bean using the 
applicable design parameters. After parsing, the com- 
30 piler 60 uses a number of rules for generating the c- 
bean. 

[01 41 ] Each property of the m-bean will be present in 
the c-bean with the same accessor methods. So, if a 
property is read-only in the m-bean, the property will be 
35 read-only in the c-bean. 

[01 42] Figure 1 5A is an illustration of a simple c-bean 
which is generated when compiling an m-bean defined 
by a code example shown in Figure 15B. In addition, the 
compiler 60 generates a file containing an implementa- 
40 tion of the Simple MO interface. 

[01 43] In addition to the property accessors, the com- 
piler 60 generates code only for public methods for 
which it makes sense to provide remote access. Other 
public methods do not appear in the c-bean generated 
45 by the compiler 60. 

[01 44] Figure 1 6A shows a subset for an action meth- 
od in a c-bean of the MO interface which the compiler 
60 will generate when compiling the action method in 
an m-bean defined as in Figure 16B. 
so [0145] If an m-bean contains a listener called A, the 
compiler 60 includes a listener called AlfMO in the c- 
bean. 

[0146] When using the c-bean, an application will 
have to implement the Aifmo interface to add or remove 
55 the listener in the c-bean. Generally, a listener is an in- 
terface containing a certain number of methods. Each 
method has one input parameter. The input parameter 
extends an event object concerned. 
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[0147] In an example, each method defined in listener 
A refers to an event object which, for the purpose of this 
example is called AnEvent. Accordingly, in the Aifmo in- 
terface, the event object is called AnEventMO. Thus, for 
a listener A, the compiler 60 generates files: 

Aifmo.java; 
AnEventMO.java. 

[0148] In addition, the compiler 60 generates an im- 
plementation of listener A named AStub.java. 
[01 49] Codes generated by the compiler 60 complies 
with the design parameters designed by the JavaBeans 
component model. Accordingly, the objects generated 
by the compiler 60 can be integrated in development en- 
vironments that comply with this model. In addition, the 
compiler 60 adds some public methods which do not fol- 
low the design patterns defined by the JavaBeans com- 
ponent model. The added methods are designed to limit 
the network traffic between an m-bean and a c-bean. 
For example, by calling one function on a c-bean, it is 
possible to read all the properties of the corresponding 
m-bean. 

[01 50] The compiler 60 generates Java source code. 
It is possible to edit the generated code and modify it to 
define a specific view of an m-bean. Instead of modifying 
both the interface and the stub, it is better to keep the 
interface and modify only the stub. The code generated 
by the compiler 60 enables an application to be built us- 
ing the interface. At one time the behaviour will change 
depending on which stubs are loaded by the adaptor- 
MO. For instance, the compiler can generate read-only 
or read-write stubs for the same interface. Accordingly, 
an m-bean browser can be developed based on the in- 
terface. As mentioned above, the browser will thereby 
have a different behaviour depending on whether the 
read-only or read-write stubs are loaded. 
[0151] The adaptorMO interface is a Java interface 
defined for managing the agent 20. The network man- 
agement system provides several implementations of 
the adaptorMO interface based on different communi- 
cations protocols, as described above. However, the 
adaptorMO interface is protocol independent. Accord- 
ingly, any piece of code written using the interface can 
run on any of the implementations provided by the net- 
work management system. 

[0152] Within the adaptorMO interface there are two 
different levels. A low level where remote objects (m- 
bean) are manipulated using their names, and a high 
level where remote objects (m-bean) are manipulated 
using a local view (c-bean) of the remote objects. The 
high level is built on top of the low level interface. 
[0153] Using the low level interface is practical for 
building generic applications (such as an HTML object 
viewer or MIB browser). Using the high level interface 
is much easier than using the lower level interface. How- 
ever, it means that the application knows the semantic 
of the c-beans it manipulates. In addition, it requires the 



application (or the adaptorMO interface) to have access 
to MOs and MOStubs. A first step in initialising an adap- 
tor consists of initialising an implementation of the adap- 
torMO interface. 

s [0154] In order to initialise an adaptor, the client ap- 
plications invokes a "connect" method defined in the 
adaptorMO interface. Parameters are provided which 
relate to the host name of the agent, the port number to 
use and a logical name which is generally dependent 

10 on the underlying communication mechanism. The dif- 
ferent piece of information could be obtained from a 
name server or directory service at the same time the 
implementation name of the adaptor to use is given. De- 
pending on the underlying communication mechanism 

15 used by the adaptorMO interface, the call to "connect" 
might not involve any message exchange between the 
client and agent. 

[0155] An adaptor makes use of: 

20 - a name server for getting the Java class name for 
use for representing a specific m-bean (known 
through its object name); 
a class loader for loading c-beans. 

25 [0156] If all the Java classes for the c-beans are 
present on the machine where the client application is 
running, there is no need to use a specific class loader. 
Otherwise, it is possible to use a network class loader 
for getting the classes over the network. 
30 [0157] For using a network class loader, a client ap- 
plication needs to instantiate the network class loader. 
When instantiating the object, the application provides 
an object name. The object name can contain any do- 
main and any class name. However, the object name 
35 should contain the following key properties: 

host (the host name where the class server is run- 
ning); 

port (the port number to use); 
40 - service (the name of the RMI service to invoke). 

[0158] Once an adaptor is initialised, the application 
is ready to perform management operations on the re- 
mote agent. An application can retrieve a subset or all 
45 of the m-beans managed by an agent. When retrieving 
objects, an application can specify queries. The results 
of the retrieval can be obtained under two different 
schemes: 

so - a list of object names (represented by a Vector); 

a list of c-beans (for each object name retrieved the 
adaptor will instantiate a c-bean). 

[01 59] In order to read a property of a remote m-bean, 
55 the property name is needed when using the low level 
adaptorMO interface level. When using the high level 
interface, the c-bean is retrieved and then a getter as- 
sociated to the property is invoked. 
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[0160] Setting a property of a remote m-bean, a prop- 
erty name and the property object type is required when 
using the low level adaptorMO interface level. When set- 
ting a value, it is possible to specify the name of an op- 
erator class. On the agent side, the specified operator 
is instantiated and invoked for setting the property value. 
When using the low level adaptorMO interface level, it 
is possible to set several properties through one method 
call using a list of modifications. 
[0161] When using the high level adaptorMO inter- 
face level, a c-bean is obtained and the developer then 
invokes the set associated to the property. 
[01 62] Through the adaptorMO interface, it is possible 
to request instantiated of m-beans within a remote 
agent. When requesting the instantiation, it is possible 
specify new class loader through which the agent is sup- 
posed to load the new class to instantiate. The class 
loader can be specified using its object name. If no class 
loader is specified, the agent uses the default class load- 
er. When instantiating a remote m-bean, it is possible to 
directly obtain a c-bean for representing the newly cre- 
ated m-bean. If no name is provided and if a name serv- 
er is specified, the adaptor queries the name server in 
order to obtain the name of the Java class to instantiate 
on the agent's side. Otherwise, it is the responsibility of 
the agent to determine the class name of the class to 
instantiate. When instantiating an m-bean in the agent, 
it is possible to explicitly request the object to be per- 
sistent. 

[01 63] Through the adaptorMO interface, it is possible 
to transfer Java objects from the client to the agent. In 
order to do this, the adaptorMO interface serialises the 
object, sends the object over and deserialises the object 
in the agent. 

[0164] Through the adaptorMO interface, it is also 
possible to remove an m-bean object from the remote 
agent. The m-bean is not removed from the virtual ma- 
chine, but only from the object repository of the agent. 
[01 65] Figure 1 7 is a flow diagram giving an overview 
of the steps in creating and operating a management 
system as described above including steps of defining 
a network management model including at least one 
management bean using a bean-based environment 
and compiling said model to implement said computer 
network management system in said bean-based envi- 
ronment. 

[0166] In step 110, a model is created using a bean- 
based environment. A preferred bean-based environ- 
ment is Java environment with the beans being Java- 
Beans. 

[0167] As mentioned above, beans provide a set of 
properties, a set of methods for performing actions, and 
support for events and for introspection. Conventionally, 
the properties allow beans to be manipulated program- 
matically and support customization of the bean, the 
methods implement the properties and the support for 
events enables beans to fire events and define the 
events which can be fired. The support for introspection 



enables the properties, events and methods of the bean 
to be inspected from externally. 

[0168] Accordingly, step 110 includes generating at 
least one said management bean providing at least one 

s property for modelling a property of a managed re- 
source, and/or a method for modelling an action for said 
managed resource and/or support for at least one event 
for modelling an event of said resource and/or support 
for introspection permitting external analysis of the com- 

10 position of said bean. This step also includes defining 
the relationship and interactions between management 
beans as representative of the relationships and inter- 
actions between the managed resources. This step can 
also include defining at least one listener event in re- 
's spect of at least one management bean. 

[0169] It is recognised for the first time in respect of 
the present network management system that beans 
can be used beyond their conventional role to provide 
a management vehicle (management bean) for directly 

20 modelling resources to be managed. For example, a 
property in a management bean can be used for mod- 
elling a property (e.g. a resource attribute such as the 
size of a memory, the number of messages received in 
a buffer, etc) of a managed resource. A method of a 

25 management bean can be used for modelling an action 
(e.g. a system rest) of a managed resource. A bean can 
also be used to provide support for an event (for exam- 
ple a disk full event) for a managed resource. For ex- 
ample, a management bean can provide support for a 

30 listener event, whereby one management bean can be 
responsive to an event on another management bean. 
By means of the support for introspection a manage- 
ment bean can permit external analysis of the compo- 
sition of the bean and the exchange of information be- 

35 tween beans. Management beans can include defini- 
tions of relationships and interactions between manage- 
ment beans as representative of the relationships and 
interaction between the managed resources. 
[0170] As beans are reusable software components 

40 which can be manipulated visually in a builder tool (e.g. 
an editor or graphical user interface builder (GUI build- 
er)), in step 110 a user can use a conventional builder 
tool, such as the JavaBeans Development Kit, for gen- 
erating the management system model including beans 

45 defining system resources, their functions and the rela- 
tionships between and interactions of the system re- 
sources. The bean model is defined within a virtual ma- 
chine forming the bean-based environment, for example 
a model using JavaBeans within a Java virtual machine. 

so This greatly facilitates the generation of the manage- 
ment system model. Verification and debugging of the 
model can be readily performed using introspection and 
other techniques. 

[0171] In step 112, once the model has been gener- 
55 ated, the model can be compiled directly using a con- 
ventional compiler for the bean-based environment, for 
example the compiler 60 shown in Figure 9. By defining 
a model in a bean-based environment, it is possible di- 
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rectly to compile the bean-based model to form a bean- 
based implementation using a standard compiler for the 
bean-based environment, for example by compiling the 
JavaBeans using a Java compiler. Accordingly, the re- 
sulting bean management system is also defined within 
the same Java environment. This greatly simplifies this 
stage of the generation of management system as the 
compiler forces a reliable and homogeneous implemen- 
tation of the model. 

[01 72] At runtime, therefore, in step 114, the manage- 
ment system described earlier in this document pro- 
vides a robust and readily modifiable structure, without 
the difficulties and disadvantages of prior network man- 
agement system. 

[0173] Step 114 includes the steps described in re- 
spect of Figure 12 of registering one or more manage- 
ment bean(s) with the extensible agent framework; reg- 
istering one or more network adaptor(s) (e.g. network 
adaptor bean(s)) for a network communications protocol 
with the extensible agent framework; and enabling ex- 
ternal access via the network to the management bean 
(s) via the network adaptor(s). 

[01 74] As described with respect to Figure 1 2, the ex- 
tensible agent framework can include an associated re- 
pository bean and the steps of registering one or more 
management bean(s) and/or network adaptor(s) can 
comprise registering one or more management bean(s) 
and/or network adaptor(s) with the repository bean. 
[0175] Thus, there has been described a network 
agent for a telecommunications network, which network 
agent includes an extensible framework, one or more 
managed objects registerable with the framework and 
one or more network adaptors registerable with the 
framework for a network communications protocol for 
enabling access to the managed objects. The network 
agent provides a flexible mechanism for a dynamic net- 
work management environment. Registration with the 
framework can be by means of a repository service ob- 
ject. The managed object is preferably a bean which 
comprises a set of properties, a set of methods and sup- 
port for events and for introspection. There has also 
been described a method of providing agent service and 
a network management system using such an agent. 
[0176] The network agent can be implemented in the 
form of software on at least one storage medium. The 
storage medium could be a portable storage medium 
such as a magnetic, opto-magnetic or optical disk and/ 
or a solid state memory and/or the memory of a server 
computer. The network agent can be loaded into mem- 
ory of a managed system by connecting the portable 
storage medium or by down-loading from the server and 
executed by the processor at the managed system. Al- 
ternatively, the network agent could be implemented, at 
least in part, by special purpose firmware or hardware. 
[0177] It will be appreciated that although particular 
embodiments of the invention have been described, 
many modifications/additions and/or substitutions may 
be made within the scope of the present invention. 



Claims 

1 . A network agent for a telecommunications network, 
said network agent comprising: 

5 

an extensible framework (24); 
one or more managed objects (25-29) register- 
able with said framework; and 
one or more network adaptors (30-38) register- 
's able with said framework for a network commu- 
nications protocol for enabling access to said 
managed objects, characterised in that a said 
managed object is a bean which comprises a 
set of properties, a set of methods for perform- 
15 ing actions, and support for events and for in- 
trospection. 

2. The network agent of Claim 1 , comprising a repos- 
itory service object (27) registrable with said frame- 

20 work, said managed object(s) and/or said network 
adaptor(s) and/or one or more further service ob- 
jects being registrable with said repository service 
object, whereby said managed object and said net- 
work adaptors are registerable indirectly with said 
25 framework via said repository service object. 

3. The network agent of Claim 2, wherein said network 
adaptor(s) comprise network adaptor object(s). 

30 4. The network agent of any preceding claim, wherein 
said framework comprises getter and setter proper- 
ties and implements getter and setter methods for 
getting and/or setting objects and/or object meth- 
ods. 

35 

5. The network agent of Claim 4, wherein a said net- 
work adaptor is responsive to a received external 
request to cause said framework to get a managed 
object method for said request and to return a sub- 

40 sequent response. 

6. The network agent of Claim 5, comprising an repos- 
itory service object registrable with said framework, 
said managed object(s) and/or said network adap- 
ts tor(s) being registrable with said repository service 

object, whereby said managed object and said net- 
work adaptors are registerable indirectly with said 
framework via said repository service object, said 
framework referencing said repository service for 
so calling said managed object method. 

7. The network agent of Claim 4, wherein said frame- 
work is arranged to effect add object and remove 
object functions. 

55 

8. The network agent of any preceding claim, wherein 
said framework is a bean which comprises a set of 
properties, a set of methods for performing actions, 
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and support for events and for introspection. 

9. The network agent of any preceding claim, wherein 
a said network adaptor comprises a network adapt- 
er object. 

10. A computing system connectable to a telecommu- 
nications network, said computing system including 
an network agent according to any one of Claims 1 
to 9. 

11. A network management system comprising a net- 
work agent according to any one of Claims 1 to 9. 

1 2. A method of providing agent services via a telecom- 
munication network, said method comprising steps 
of: 

dynamically registering one or more managed 
objects (25-29) with an extensible agent frame- 
work; 

registering one or more network adaptors 
(30-38) for a network communications protocol 
with said framework; and 
enabling access to said managed object(s) via 
said network adaptor(s) characterised in that 
a said managed object is a bean which com- 
prises a set of properties, a set of methods for 
performing actions, and support for events and 
for introspection. 

13. The method of Claim 12, wherein said framework 
comprises an associated repository object (27) and 
said registering steps comprise registering said 
managed objects and/or said network adaptors with 
said repository object. 

14. The method of Claim 13, wherein a said network 
adaptor is responsive to a received external request 
to cause said framework to call a managed object 
method for said request and to return a subsequent 
response. 

15. The method of Claim 14, wherein a said network 
adaptor comprises a network adaptor object. 

Patentanspruche 

1 . Ein Netzagent fur ein Telekommunikationsnetz, wo- 
bei der Netzagent aufweist: 

ein erweiterbares Rahmenwerk bzw. Bezugs- 
system (24); 

ein oder mehrere verwaltete Objekte (25-29), 
die bei dem Rahmenwerk registriert werden 
konnen; und 

ein oder mehrere Netzadapter (30-38), die bei 



dem Rahmenwerk fur ein Netzkommunikati- 
onsprotokoll registriert werden konnen, um Zu- 
griff auf die verwalteten Objekte zu ermogli- 
chen, charakterisiert dadurch, da(3 ein verwal- 
s tetes Objekt eine Bean ist, die einen Satz von 

Eigenschaften, einen Satz von Methoden zum 
Durchfuhren von Aktionen und Unterstutzung 
fur Ereignisse und zur Selbstpmfung bzw. In- 
trospektion aufweist. 

10 

2. Der Netzagent nach Anspruch 1 , der ein Ablage- 
bzw. Speicherdienstobjekt (27) aufweist, das bei 
dem Rahmenwerk registriert werden kann, wobei 
(ein) verwaltete(s) Objekt(e) und/oder Netzadapter 

15 und/oder ein oder mehrere weitere Dienstobjekte 
bei dem Speicherdienstobjekt registriert werden 
konnen, wobei das verwaltete Objekt und die 
Netzadapter iiber das Speicherdienstobjekt indirekt 
bei dem Rahmenwerk registriert werden konnen. 

20 

3. Der Netzagent nach Anspruch 2, wobei (ein) 
Netzadapter (ein) Netzadapterobjekt(e) aufweist 
bzw. aufweisen. 

25 4. Der Netzagent nach einem der vorstehenden An- 
spruche, wobei das Rahmenwerk Hoi- und Setz-Ei- 
genschaften aufweist und Hoi- und Setz-Methoden 
implementiert, um Objekte und/oder Objektmetho- 
den zu holen und/oder zu setzen. 

30 

5. Der Netzagent nach Anspruch 4, wobei ein Netzad- 
apter auf eine empfangene externe Anforderung 
reagiert, um das Rahmenwerk zu veranlassen, eine 
Methode eines verwalteten Objektes fur diese An- 

35 forderung zu holen und eine anschlieRende Antwort 
zumckzugeben. 

6. Der Netzagent nach Anspruch 5, der ein Speicher- 
dienstobjekt aufweist, das bei dem Rahmenwerk re- 

40 gistriert werden kann, wobei (ein) verwaltete(s) Ob- 
jekt(e) und/oder (ein) Netzadapter bei dem Spei- 
cherdienstobjekt registriert werden konnen, wobei 
das verwaltete Objekt und die Netzadapter iiber 
das Speicherdienstobjekt indirekt bei dem Rah- 

45 menwerk registriert werden konnen, wobei das 
Rahmenwerk den Speicherdienst referenziert, um 
die Methode des verwalteten Objekts aufzurufen. 

7. Der Netzagent nach Anspruch 4, wobei das Rah- 
so menwerk darauf ausgelegt ist, Funktionen zum Hin- 

zufugen und zum Entfernen eines Objektes zu be- 
wirken. 

8. Der Netzagent nach einem der vorstehenden An- 
55 spruche, wobei das Rahmenwerk eine Bean ist, die 

einen Satz von Eigenschaften, einen Satz von Me- 
thoden zum Durchfuhren von Aktionen und Unter- 
stutzung fur Ereignisse und zur Selbstpmfung bzw. 
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Introspektion aufweist. 

9. Der Netzagent nach einem der vorstehenden An- 
spruche, wobei ein Netzadapter ein Netzadapter- 
Objekt aufweist. 

10. Ein Rechnersystem, das mit einem Telekommuni- 
kationsnetz verbunden werden kann, wobei das 
Rechnersystem einen Netzagenten nach einem der 
Anspmche 1 bis 9 aufweist. 

1 1 . Ein Netzmanagementsystem, das einen Netzagen- 
ten nach einem der Anspmche 1 bis 9 aufweist. 

12. Ein Verfahren zum Bereitstellen von Agentendien- 
sten iiber ein Telekommunikationsnetz, wobei das 
Verfahren die Schritte aufweist: 

dynamisches Registrieren von einem oder 
mehreren verwalteten Objekten (25-29) bei ei- 
nem erweiterbaren Agenten-Rahmenwerk; 
Registrieren eines oder mehrerer Netzadapter 
(30-38) fur ein Netzkommunikationsprotokoll 
bei dem Rahmenwerk; und 
Ermoglichen eines Zugriffs auf (ein) verwaltete 
(s) Objekt(e) iiber (den) Netzadapter, charak- 
terisiert dadurch, da(3 ein verwaltetes Objekt 
eine Bean ist, die einen Satz von Eigenschaf- 
ten, einen Satz von Methoden zum Durchfuh- 
ren von Aktionen und Unterstutzung fur Ereig- 
nisse und zur Selbstpmfung aufweist. 

13. Das Verfahren nach Anspruch 12, wobei das Rah- 
menwerk ein zugeordnetes Speicherobjekt (27) 
aufweist und die Schritte zum Registrieren das Re- 
gistrieren des verwalteten Objektes und/oder der 
Netzadapter bei dem Speicherobjekt aufweisen. 

14. Das Verfahren nach Anspruch 13, wobei ein 
Netzadapter auf eine empfangene externe Anfor- 
derung reagiert, um das Rahmenwerk zu veranlas- 
sen, eine Methode eines verwalteten Objektes fur 
diese Anforderung aufzurufen und eine anschlie- 
Rende Antwort zumckzugeben. 

15. Das Verfahren nach Anspruch 14, wobei ein 
Netzadapter ein Netzadapter-Objekt aufweist. 

Revendications 

1. Agent de reseau pour un reseau de telecommuni- 
cations, ledit agent de reseau comprenant : 



seau enregistrables avec ledit cadre pour un 
protocole de communications par reseau pour 
permettre I'acces auxdits objets geres, carac- 
terise en ce qu'un dit objet gere est un bean 
s qui comprend un ensemble de proprietes, un 

ensemble de methodes pour effectuer des ac- 
tions, et un support pour des evenements et 
pour introspection. 

10 2. Agent de reseau selon la revendication 1 , compre- 
nant un objet (27) de service de referentiel enregis- 
trable avec ledit cadre, le ou lesdits objets geres et/ 
ou le ou lesdits adaptateurs de reseau et/ou un ou 
plusieurs objets supplementaires de service etant 

15 enregistrables avec ledit objet de service de refe- 
rentiel, ce par quoi ledit objet gere et lesdits adap- 
tateurs de reseau sont enregistrables indirectement 
avec ledit cadre via ledit objet de service de refe- 
rentiel. 

20 

3. Agent de reseau selon la revendication 2, dans le- 
quel le ou lesdits adaptateurs de reseau compren- 
nent un ou des objets d'adaptateur de reseau. 

25 4. Agent de reseau selon I'une quelconque des reven- 
dications precedentes, dans lequel ledit cadre com- 
prend des proprietes d'acquereur et de parametreur 
et met en oeuvre des methodes d'acquereur et de 
parametreur pour acquerir et/ou parametrer des ob- 
30 jets et/ou des methodes d'objet. 

5. Agent de reseau selon la revendication 4, dans le- 
quel un dit adaptateur de reseau est sensible a une 
demande externe recue pour faire que ledit cadre 

35 acquiere une methode d'objet gere pour ladite de- 
mande et renvoie une reponse ulterieure. 

6. Agent de reseau selon la revendication 5, compre- 
nant un objet de service de referentiel enregistrable 

40 avec ledit cadre, le ou lesdits objets geres et/ou le 
ou lesdits adaptateurs de reseau etant enregistra- 
bles avec ledit objet de service de referentiel , ce par 
quoi ledit objet gere et lesdits adaptateurs de re- 
seau sont enregistrables indirectement avec ledit 
45 cadre via ledit objet de service de referentiel, ledit 
cadre faisant reference audit service de referentiel 
pour appeler ladite methode d'objet gere. 

7. Agent de reseau selon la revendication 4, dans le- 
so quel ledit cadre est agence pour effectuer I'ajout 

d'objet et pour retirer des fonctions d'objet. 

8. Agent de reseau selon I'une quelconque des reven- 
dications precedentes, dans lequel ledit cadre est 
un bean qui comprend un ensemble de proprietes, 
un ensemble de methodes pour effectuer des ac- 
tions, et un support pour des evenements et pour 
introspection. 



un cadre extensible (24) ; 55 
un ou plusieurs objets geres (25 a 29) enregis- 
trables avec ledit cadre ; et 
un ou plusieurs adaptateurs (30 a 38) de re- 
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9. Agent de reseau selon I'une quelconque des reven- 
dications precedentes, dans lequel ledit adaptateur 
de reseau comprend un objet d'adaptateur de re- 
seau. 

5 

10. Systeme informatique pouvant etre connecte a un 
reseau de telecommunications, ledit systeme infor- 
matique incluant un agent de reseau selon I'une 
quelconque des revendications 1 a 9. 

10 

11. Systeme de gestion de reseau comprenant un 
agent de reseau selon I'une quelconque des reven- 
dications 1 a 9. 

12. Procede defourniturede services d'agent via un re- '5 
seau de telecommunications, ledit procede com- 
prenant les etapes : 

d'enregistrement de maniere dynamique d'un 

ou plusieurs objets geres (25 a 29) avec un ca- 20 

dre d'agent extensible ; 

d'enregistrement d'un ou plusieurs adaptateurs 
(30 a 38) de reseau pour un protocole de com- 
munications par reseau avec ledit cadre ; et 
d'autorisation d'acces audit ou auxdits objets 25 
geres via ledit ou lesdits adaptateurs de re- 
seau, caracterise en ce que ledit objet gere 
est un bean qui comprend un ensemble de pro- 
prietes, un ensemble de methodes pour effec- 
tuer des actions, et un support pour des evene- 30 
ments et pour introspection. 

1 3. Procede selon la revendication 1 2, dans lequel ledit 
cadre comprend un objet (27) de referentiel associe 

et dans lequel lesdites etapes d'enregistrement 35 
comprennent I'enregistrement desdits objets geres 
et/ou desdits adaptateurs de reseau avec ledit objet 
de referentiel. 

14. Procede selon la revendication 13, dans lequel un 40 
dit adaptateur de reseau est sensible a une deman- 

de externe recue pour faire que ledit cadre appelle 
une methode d'objet gere pour ladite demande et 
renvoie une reponse ulterieure. 

45 

15. Procede selon la revendication 14, dans lequel un 
dit adaptateur de reseau comprend un objet d'adap- 
tateur de reseau. 



55 
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package sunw.jaw.example.mo.Simple; 
/** 

* Generated by mogen Compiler version; 

@ (#) Main.java 1.11 97/05/16 SMi 

*/ 

import java.jaw.common.*; 
import java.jaw.client.mo.*; 

public interface SimpleMO extends ManagedObject { 
public String getState() 

throws InstanceNotFoundException, CommunicationException, 
IHegalAccessException, ServiveNotFoundException, 
PropertyNotFoundException; 

public Integer getNbChanges 0 
throws InstanceNotFoundException, CommunicationException, 
IHegalAccessException, ServiceNotFoundException, 
PropertyNotFoundException; 

public void setState (String value) 

throws InstanceNotFoundException, CommunicationException, 
IHegalAccessException, ServiceNotFoundException, 
PropertyNotFoundException, InvalidPropertyValueException, 
InstantiationException, ClassNotFoundException; 



} 
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package sunw.jaw.example.mo. Simple; 

r* 

* Very simple of definition of a Beans MO 

* No special import required. 
7 

public class Simple implements java.io.Serializable { 
private String state; 
private Integer nbChanges; 

public Simple () { 

state = "construct"; 
nbChanges = new Integer (0); 

} 

public String getState 0 { 
return (state); 

} 

public void setState (String s) { 
state = s; 

nbChanges = new Integer (nbChanges. intValue () + 1); 

} 

public Integer getNbChanges () { 
return (nbChanges) ; 

} 



FIG. 15B 
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public interface simpleMBeanMO extends ManagedObject { 

public Boolean performReverse (integer pO) 

throws InstanceNotFoundException, CommunicationException, 
lllegalaccessException, ServiceNotFoundException, 
NoSuchMethodException; 

public void performReverse 
throws InstanceNotFoundException, CommunicationException, 
IliegalAccessException, ServiceNotFoundException, 
NoSuchMethodexception; 



FIG.16A 



public class simpleMBean implements java.io.Serializable { 

public void performReverse 0 { 

StringBuffer buf = new StringBuffer (name); 

name = buf. reverse 0-toString (); 

} 

public Boolean performReverse (Integer nFirst) { 
StringBuffer buf = new StringBuffer 0; 
int n = nFirst. intValueO; 

if (name. length 0 < n + 1) { 
return (new Boolean (false)); 
} 

buf.append (name.substring (0, n)); 

name = new String (buf.reverse Q.toString 0 + 
name.substring (n)); 

return (new Boolean (true)); 

} 

} 



FIG. 16B 
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